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A graphics user interface called GLAD (Graphics LAnguage for Database) is 
proposed as a unified interface method for a user interaction with a database. GLAD 
provides a coherent interaction method for all three user interactions with a database: 
data definition interaction, data manipulation interaction, and program development 
interaction. In this paper, the features of data manipulation interaction of GLAD are 
described. Specifically, the method of representing and manipulating 
generalized/specialized objects and recursively related objects is presented, and the 
notion of program box which is used for specifying a complex query is introduced. 



1. Introduction 



To attain a wider acceptance and usage, a database management system must 
accommodate more different types of users. These users range from very sophisticated 
users, such as database administrators and system designers, to naive users, such as 
secretaries, clerks, and other non-technical users of database. In this paper, we describe 
a graphical user interface that accommodates both sophisticated and naive users. 

Users of a database management system interact with a database in three different 
ways. The first is the creation of database 1 via a data definition language. The second 
is the accessing (i.e. retrieval and update of information) of database via a data 
manipulation language. And the last is the development of application programs via an 
embedded host language (i.e. a regular programming language embedded with a data 
manipulation language). We call these three different user interactions, respectively, 
data definition interaction, data manipulation interaction and program development 
interaction. In a relational database management system INGRES, for example, a query 
language called QUEL is provided for data manipulation and definition, and an 
embedded query language called EQUEL/C is provided for developing application 
programs. To utilize these specialized languages successfully, users must be well versed 
in computer programming concepts. 

In a traditional data processing application of database management system, naive 
users’ interation with a database is usually limited to the accessing of database; thus, the 
previoulsy proposed "user-friendly" interfaces are concentrated on the data manipulation 
interaction. A "canned" menu-driven query system, where each choice in the menu is a 
specific query such as "list all customers with outstanding balance," is a common user 
interface employed for accessing a database. Problems with the canned menu-driven 

*By creation of database, we mean the definition of database schema and not the actual loading of data into the database. 
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query system are that it can only be used by naive users (it is too tedious for 
sophisticated users) and that it has very limited querying capability (users can only ask 
what the menu provides). 

New proposals for a better data manipulation interface can be classified into three 
different approaches: a natural language interface, a modified query language interface, 
and a graphics interface. A natural language interface [BOGU84, CODD74, HEND77, 
WALTS78] is primarily developed for naive users, and therefore, it may not be suitable 
for more sophisticated users. Pros and cons for using a natural language interface as a 
database access method are presented in [PETR76]. The second approach, a modified 
query language interface [KORT84, MACG85], employs a similar syntax as a regular 
query language but with more simplified syntax and enriched semantic. It is intended 
for both sophisticated and naive users. The third approach, a graphics interface 
[HERO80, LARS84, MCD074, STON82, SUGI84, WONG82, WU85, ZL0077], uses 
graphic objects as a tool for accessing database. This approach is also intended for both 
types of users. 

As a better interface for program development interaction, so called Fourth 
Generation Languages are proposed. These commercial products are advertised as so 
easy to use that non-technical managers can develop their own application programs by 
themselves. Although we feel that these Fourth Generation Languages are in general 
easier to use than embedded host languages, we view these advertisers’ claims more of a 
sales gimmick. A much better approach called fill-in-the-form programming for an 
application program development is reported in [ROWE85]. With this approach, a user 
develops a complete application by interactively composing a collection of frames, which 
consists of forms to display/enter data and a menu of operations. 
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Expressing the conceptual schema of database, once it is designed, in a data 
definition language is the easiest of all three interactions. And therefore, not much effort 
has been done to build a good interface for data definition interaction. However, we feel 
that just providing a syntactic mean to express the conceptual schema of database is not 
enough. A good user interface for data definition interaction, we believe, should aid 
users in the design process. GAMBIT [BRAG84] is one such interactive user interface: 
however, it is intended primarily for database adm 4 astrators and not for naive users. 

A database management system must provide a good user interface for all three 
interactions to make the system easy to use and learn for both sophisticated and naive 
users. We should note that simply combining some of the aforementioned proposals is 
not acceptable, because users must learn three different interaction methods to utilize the 
database management system. We believe that a single, coherent interation method 
must be provided for all three interactions in order to gain an acceptance and to increase 
a usage of database management system by a wider audience. 

We believe a graphical interface has the best potential in developing such single, 
coherent interaction method applicable to all three interactions, and thus, we propose a 
graphical interface GLAD (Graphics LAnguage for Database). GLAD has two major 
advantages. First, it provides a single environment where different techniques proposed 
for different purposes can be integrated. Specifically, in GLAD, techniques proposed in 
QBE, GUIDE, TIMBER, G-W r HIZ, etc are all integrated into a single working whole. 
Rather than re-inventing a wheel, we provide a framework where different, previously 
proposed techniques are integrated into one unit, which we believe is a much better 
approach. Second, GLAD maintains a high degree of data independence. GLAD is not 
tied to any specific implementation and therefore, it can serve as a front-end to relational 
or network DBMS. And it is also possible to have a specialized implementation for 
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GLAD Since GLAD can be attached to relational or network DBMS, many existing 
databases can become available (by having GLAD front-end) to all users who learn 
GLAD. 

A major contribution of GLAD to a user interface research is its single, unified 
interface method for all three interactions. By providing a coherent interface method. 
GLAD achieves a high degree of ease of learning and using. To our knowledge, there is 
no other proposal that addresses the issue of a unified interface method for all three user 
interactions. Specific contributions of this paper are the presentation of simple graphical 
representations for different types of generalized/specialized and recursively related 
objects and the introduction of program box concept. GLAD is the first graphical 
interface that can represent these objects and allow users to manipulate them in a simple 
fashion. 

The paper is organized as follows. The characteristics of a good user interface for 
data manipulation and an overall description of a data manipulation interaction via 
GLAD are given in the next section. Section 3 illustrates a data manipulation interaction 
via GLAD by going through a sample session. Section 4 and 5 discuss the representation 
and manipulation of generalized/specialized objects and recursively related objects, 
respectively. Section 6 introduces the notion of program box which is used as an aid in 
formulating complex queries. And finally, Section 7 concludes the paper. 

2. Data Manipulation Via GLAD 

A good user interface for data manipulation interaction capable of supporting both 
sophisticated and naive users must have the following characteristics: 

(1) It must be descriptive. It must show what kinds of data (employee, department, 

equipment, etc) are stored in the database and how they are related to each other. 
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We call such representation of data and their rela ionships database schema. Also, 
it should provide a help (i.e. describe more about the database) if requested by 
users. 

(2) It must be powerful. Users must be able to express a complex query by using it 

(3) It must be easy to learn. Naive and uninitiated users should be able to master the 
interaction method quickly and start accessing the database with a short learning 
period. 

(4) It must be easy to use. It must be easy to use so users rarely make erroneous 
queries and can formulate complex queries simply and quickly. Also, users should 
be able to specify a query in different ways; they should not be forced to remember 
a particular way to pose a query. 

Query languages of currently available database management systems lack in all 
characteristics but (2). 

A review of previously proposed graphics user interfaces [HERO80, LARS84, 
MCD074, STON82, SUGI84, WONG82, ZL0077] by using the criteria listed above as a 
yardstick is given in [WU85]. We shall simply note here that none of them attains all 
four characteristics satisfactorily. A graphics user interface for data manipulation 
interaction that we describe here can be viewed as a synthesis of previoulsy proposed 
graphics user interfaces. By incorporating their good features and eliminating their weak 
points, we believe that GLAD has achieved a higher degree of descriptivenes, ease of 
learning and using, and power. 

For ease of reference, we shall call the part of GLAD that deals with the data 
manipulation interaction GLAD DMC (Data Manipulation Component). In the 
following, we describe the salient features of GLAD DMC. These features are 
categorized into four characteristics mentioned above. 
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2.1. GLAD DMC is descriptive 



GLAD DMC displays a diagram of the database schema. This GLAD diagram is 
semantically rich, which means that it is capable of capturing a real world semantics 
(how the information stored in the database are related to each other) naturally and 
precisely. Conventional data models, such as relational, network, and hierarchical data 
models are semantically poor compared to new data models, such as SDM, TAXIS, E/R, 
etc. A GLAD diagram is applicable to many semantic data models 2 , because it provides 
an elegant diagrammatic representation of real world abstraction concepts those 
semantic data models employ. The abstraction concepts we are dealing with here are: 
aggregation, generalization, and classification. In the following, we discuss each of them 
and show how each is represented in a GLAD diagram. 

Aggregation: 

An object 3 is an aggregation of (sub)objects. For example, a student object could 
be an aggregation of name, address, ssno. gpa, and dept (sub)objects. An aggregate 
object is represented as a rectangle in a GLAD diagram, see Figure 2.1a. A user can see 
the sub(objects) of an aggregate object by expanding it, see Figure 2.1b. Notice that the 
dept object is not shown in Figure 2.1b because it is not an atomic object. Only first 
four objects are atomic ; that is. they are an aggregation of exactly one system-defined or 
a user-defined base object (string, number, enumeration, subrange and boolean). Since 
the dept object is an non-atomic aggregate object, say, an aggregation of name, set of 
students, set of courses, and school, it was not shown in Figure 2.1b. Each non-atomic 
object in the database is displayed 4 , and an association between objects is represented as 
a line between these objects, see Figure 2.1c. Notice that the dept object is shown as a 

2 Although we feel that a GLAD diagram is applicable to almost all semantic models, there may be some data models that we 
are unaware of or do not fully understand. Therefore, we shall refrain ourselves from making such claim until further study is made. 

3 We do not define the term object here; we intuitively view an object as a "thing" (both tangible and intangible) that exists. 

4 A database designer can modify it so a non-atomic object is not displayed. 
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separate rectangle. Notice also that an association is not labelled. We discus> the issue 
of labelling an association in Section 5. 

Generalization: 

Individual objects, such as faculty, secretary, and technician, can be grouped 
together to form a generalized object, say, employee. Faculty, secretary, and technician 
objects are called specialized objects of employee. Generalization abstraction can be 
characterized as an IS-A relationship (faculty IS- A emloyee, etc.). 

A generalized object is represented in a GLAD diagram as a nested rectangle, see 
Figure 2.2a. A user can expand the nested rectangle and view the specialized objects, see 
Figure 2.2b. These specialized objects can themselves be the generalized objects of yet 
further specialized objects. A faculty object, for example, can be a generalized object of 
full, associate, and assistant professors. Graphical representations of different types of 
generalized/specialized objects are given in the next section. 

We have already mentioned in the previous subsection that an association between 
objects is represented as a solid line in a GLAD diagram. When one or both of the 
associated objects are specialized objects, a dotted line is used. Figure 2.3 shows how the 
dotted lines are used in a GLAD diagram. 

An aggregate object can have a disjunctive association, which means that an object 
can have either one (sub)object or another. We use a small circle to show a disjunctive 
association. Figure 2.4 says that an equipment can belong either to a department or to a 
school. 

Classification: 

Each data item stored in a database is information about some object. For 
example, data item [bruce springsteen, n. j., 123-45-6789. 3.2, music] is an information 
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about student, and it is classified as a student object. We call each data item of an 
object a member of that object. 

2.2 GLAD DMC is easy to learn 

The number of concepts a user has to learn in order to access a database via GLAD 
DMC is few, and the interaction method is consistent throughout the interface. Circle, 
regular and nested rectangles 5 . and solid and dotted lines are the only concepts that a 
user need learn to understand the GLAD diagrams. Morever, the HELP and 
DESCRIBE commands are always available to a user. The interaction method is also 
very straightforward. A user will select the operation by first moving the mouse to the 
desired operation and then clicking the mouse button. A user can also select the 
operation by pressing the corresponding function key or by typing the operation name. 
After selecting a desired operation, a user must select an argument(s) (by moving the 
mouse to the desired argument and clicking the mouse button) that the chosen operation 
will be executed on. For example, a user will first select an operation LIST MEMBER 
and then select an argument subject to list all subject matters stored in the database. 
The result is shown in Figure 2.5. The complete result cannot fit into a window and 
therefore, only seven subject matters are displayed in the window. A user can browse 
the data by moving the small square vertically or by positioning the mouse at the arrow 
and pressing the mouse button. In GLAD DMC, a user may reverse the sequence of 
interaction, that is, a user selects argument(s) first and then selects the operation. This 
flexibility helps users learn the interaction method easily. 

For more complex retrieval operations, a QBE-like interface is used. The notable 
difference between ours and the original QBE is that ours does not need the use of 
variables for queries involving more than one objects (relations in the original QBE). 

The third type, repeated rectangle, is used to represent a recursively related ojbects. 
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The results of various psychological studies that demonstrate QBE's ease of learning and 
using are well documented in [THOM75]. By avoiding the use of variables and by 
displaying the database schema, we believe ours is easier to learn and use. 

2.3. GLAD DMC is powerful 

GLAD DMC’s power to express a complex query is a direct consequence of adopting 
a QBE-like interface for specifying a query. QBE is relationally complete, which 
guarantees that it is capable of expressing any query that can be expressed in relational 
algrebra or relational calculus. This relational completeness is a general criteria used to 
prove the expressive power of a query language. Because GLAD DMC has inherited all 
the querying capabilities of QBE, GLAD DMC is also relationally complete. 

2.4. GLAD DMC is easy to use 

GLAD DMC’s flexibility of allowing a user to formulate a query in different ways 
and in incremental, piece-by-piece fashion makes it easy to use. By allowing a user to 
pose a query in different ways, it appeals to the wider range of users. If there is only one 
way to pose a query, it probably would not appeal to all users, because the allowed query 
specification may be too difficult to naive users or may be too cumbersome for 
sophisticated users. Each user has his own preferred way of specifying a query, and the 
user interface should allow different ways of specifying the same query as much as 
possible. 

Incremental query specification would also appeal to the wide range of users. 
Rather than writing the specification for a complete query and executing it, GLAD DMC 
users can retrieve the result of the complete query in a piece-bv-piece, incremental 
manner. A user formulate the complete query by first (mentally) decomposing the query 
into smaller subqueries. After specifying each subquery correctly, he combines them to 
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